server/routes/auth.ts (1)

140-147: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Persist plexUuid when updating an existing Plex-linked user.

On Line 141+, the login refresh updates Plex fields but skips plexUuid. Users upgraded from older data can stay plexUuid = null, which breaks UUID-based watchlist flows.

Suggested patch

           user.plexToken = body.authToken;
           user.plexId = account.id;
+          user.plexUuid = account.uuid ?? user.plexUuid;
           user.avatar = account.thumb;
           user.email = account.email;
           user.plexUsername = account.username;
           user.userType = UserType.PLEX;

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@server/routes/auth.ts` around lines 140 - 147, The update block that
refreshes Plex-linked user fields sets plexToken, plexId, avatar, email,
plexUsername and userType but omits persisting plexUuid; set user.plexUuid =
account.uuid (or the correct UUID property returned on the Plex account object)
before calling userRepository.save(user) so legacy users get their plexUuid
populated and saved. Ensure you reference the existing variables user, account
and the save call (userRepository.save) in the same update flow.

server/routes/discover.ts (1)

927-929: ⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Pagination contract is currently broken for Plex watchlist.

Line 927 computes offset pagination, but Line 978 ignores it and always fetches by UUID without cursor input. page > 1 can therefore return incorrect/duplicate results.

Also applies to: 977-983

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@server/routes/discover.ts` around lines 927 - 929, The pagination logic
computes page and offset (page, offset, itemsPerPage) but the watchlist fetch
path still ignores offset and always fetches by UUID, causing duplicates for
page > 1; update the watchlist retrieval (the call around the code that fetches
by UUID in this route handler) to accept pagination arguments (offset/limit or a
cursor) and pass itemsPerPage and offset (or page) through to the data access
method (e.g., modify getWatchlistItemsByUUID or replace it with a paginated
method) so that results are limited and offset correctly for pages > 1; ensure
the same fix is applied to the other occurrence referenced (the block around
lines 977–983) so both branches honor the computed offset and itemsPerPage.

server/routes/user/index.ts (1)

687-698: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Update plexUuid for already-existing users during Plex import.

On Line 687+, existing users are refreshed with Plex profile data, but plexUuid is never updated. This leaves legacy users without the UUID required by watchlist fetches.

Suggested patch

           if (user) {
             // Update the user's avatar with their Plex thumbnail, in case it changed
             user.avatar = account.thumb;
             user.email = account.email;
             user.plexUsername = account.username;
+            user.plexUuid = account.uuid ?? user.plexUuid;

             // In case the user was previously a local account
             if (user.userType === UserType.LOCAL) {
               user.userType = UserType.PLEX;
               user.plexId = parseInt(account.id);
             }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@server/routes/user/index.ts` around lines 687 - 698, When updating an
existing user in the if (user) block in server/routes/user/index.ts, also set
the user's plexUuid from the Plex account payload before saving; e.g. assign
user.plexUuid = account.uuid || account.id (or account.uuid if present)
alongside the existing lines that set avatar/email/plexUsername and plexId, then
call userRepository.save(user) as before so legacy users receive the required
UUID for watchlist fetches.

server/api/plextv.ts (2)

434-445: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Don't collapse every Plex failure into the access-denied sentinel.

The catch block always returns endCursor: undefined, which is the same signal the callers use for an inaccessible watchlist. That means a transient timeout/5xx/schema issue can surface as WatchlistAccessDenied in usersettings.ts, and watchlistsync.ts can disable both sync toggles for a user even though access was never actually denied.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@server/api/plextv.ts` around lines 434 - 445, The catch block in
server/api/plextv.ts currently maps every error to the access-denied sentinel
(endCursor: undefined); change it so that you only return that sentinel when the
error is an actual access-denied response (e.g., HTTP 401/403 or a Plex auth
error), otherwise do not swallow the error—either rethrow the exception or
return a non-sentinel response so callers can distinguish
transient/server/schema failures; update the catch handling around logger.error
to inspect e.status/e.code (or error message patterns) and only return the
access-denied shape for true auth errors, leaving other errors to propagate.

---

391-394: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Use watchlistItem.id instead of accessing a non-existent property.

WatchlistResponse.data.user.watchlist.nodes is declared as { id: string }[], so watchlistItem.ratingKey does not exist on this type. Use watchlistItem.id in the log message.

Suggested fix

-                `Item with ratingKey ${watchlistItem.ratingKey} returned no metadata, skipping.`,
+                `Item with id ${watchlistItem.id} returned no metadata, skipping.`,

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@server/api/plextv.ts` around lines 391 - 394, The log message in the block
that checks if (!metadata) uses a non-existent property watchlistItem.ratingKey;
change it to use watchlistItem.id instead so the logger.warn call references the
correct property (e.g., `Item with id ${watchlistItem.id} returned no metadata,
skipping.`) within the same `if (!metadata)` block where `watchlistItem` and
`metadata` are checked (the logger.warn call).

server/api/plextv.ts (1)

375-445: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Don't map generic failures to the access-denied sentinel.

Non-404 metadata errors are rethrown at Lines 382-383, and the outer catch then returns { endCursor: undefined }. The callers in this PR use that shape as “watchlist not accessible”, so a transient Plex/community failure or one bad metadata fetch can incorrectly block watchlist sync for a user who actually has access.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@server/api/plextv.ts` around lines 375 - 445, The outer catch currently
swallows all errors and returns the "access-denied sentinel" (endCursor:
undefined), which causes transient or unrelated failures to be treated as “no
access”; change the final catch so it only maps explicit access-denied errors
(e.g. e.response?.status === 401 || e.response?.status === 403) to the sentinel
and otherwise rethrows the error (or preserve the cached endCursor via
cachedWatchlist?.response.data?.user.watchlist.pageInfo.endCursor) so transient
failures are not misclassified; update the catch block that currently logs via
logger.error('Failed to retrieve watchlist items', ...) and returns { first,
after, endCursor: undefined, ... } to perform the status check and rethrow for
non-access errors.